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Abstract 

We  establish  a  series  of  equivalences  between  type  systems  and  control-flow  analyses.  Specifically, 
we  take  four  type  systems  from  the  literature  (involving  simple  types,  subtypes  and  recursion) 
and  conservatively  enrich  them  to  reason  about  control-flow  information.  Similarly,  we  take  four 
standard  control-flow  systems  and  conservatively  enrich  them  to  reason  about  type  consistency.  Our 
main  result  is  that  for  each  type  system,  there  is  a  control-flow  system  with  equivalent  reasoning 
power.  In  essence,  type  systems  and  control-flow  analysis  can  be  viewed  as  complementary 
approaches  for  addressing  questions  of  type  consistency  and  control-flow. 


This  work  was  sponsored  by  the  Advanced  Research  Projects  Agency,  CSTO,  under  the  title  “The  Fox  Project: 
Advanced  Development  of  Systems  Software”,  ARPA  Order  No.  8313,  issued  by  ESD/AVS  under  Contract  No.  F19628- 
91-C-0168. 

The  views  and  conclusions  contained  in  this  document  are  those  of  the  authors  and  should  not  be  interpreted  as 
representing  the  official  policies,  either  expressed  or  implied,  of  ARPA  or  the  U.S.  Government. 


1  Introduction 


A  central  concept  in  compiler  optimization  and  code  generation  is  a  graph  of  how  control  can 
flow  from  one  program  point  to  another.  Such  a  graph  identifies  block  and  loop  structure  in  a 
program,  and  this  is  the  starting  point  for  a  large  number  of  optimizations.  In  many  languages,  this 
control-flow  graph  can  be  directly  constructed  from  a  program  because  information  about  flow  of 
control  from  one  point  to  another  is  explicit.  However,  in  a  language  with  higher-order  functions, 
the  flow  of  control  from  one  point  to  another  is  not  readily  apparent  from  program  text  because 
a  function  can  be  passed  around  as  data  and  subsequently  called  from  anywhere  in  the  program. 
If  this  happens  .sufficiently  often,  then  the  lack  of  control-flow  information  can  significantly  limit 
compiler  performance.  To  addresses  this  issue,  systems  for  control-flow  analysis  [3,  4,  10,  2,  8] 
have  been  developed.  The  purpose  of  control-flow  analysis  is  to  compute  an  approximation  of  the 
possible  functions  that  can  be  called  from  each  program  point. 

in  contrast,  the  purpose  of  a  type  inference  system  is  to  derive  invariants  about  the  potential 
binding.s  of  variables  in  a  program.  However,  in  the  context  of  higher-order  functions,  functions 
can  be  data  and  therefore  can  be  bound  to  variables.  Hence,  there  is  an  intuitive  connection 
between  reasoning  about  function  (in  control-flow  analysis)  and  reasoning  about  the  data  values  to 
which  variables  may  be  bound  (in  type  inference).  In  fact  it  is  possible  to  extend  type  systems  to 
perform  control-flow  analysis  [11,1 2],  and  conversely,  extend  control-flow  systems  to  perform  type 
analysis  [7,  8].  There  are  also  informal  connections  between  the  kinds  of  reasoning  done  by  type 
and  control-flow  systems.  For  example,  consider  the  essence  of  the  application  rule  of  a  subtype 
system: 

if  M  has  type  rj  — >  rj  and  A'  has  type  t[  such  that  then  [\I  A')  has  type  ri 

Contrast  this  with  a  control-flow  view  of  (A/  A'):  if  the  results  of  M  are  de.scribed  by  t[  and  the 
functions  that  flow  to  Af  are  such  that,  when  called  on  arguments  described  by  some  rj  such  that 
r|  includes  ,  they  return  result.^  that  are  described  by  73,  then  it  is  correct  to  use  ri  to  describe  the 
results  returned  by  (A/  A'^). 

Despite  these  informal  .similarities,  type  systems  and  control-flow  system  possess  quite  different 
structure.  Type  systems  are  typically  specified  using  deductive  systems.  Such  systems  associate 
a  type  with  each  program  expression  and  thi.s  type  completely  captures  the  type  system’s  view  of 
the  behaviour  of  the  expression.  These  systems  are  compositional  and  often  have  direct  application 
to  modular  analysis  and  separate  compilation.  In  contrast,  control-flow  analysis  systems  typically 
reason  globally  using  finite  sets  of  “function  labels”.  Such  presentations  are  rarely  compositional, 
but  they  are  often  more  suggestive  of  feasible  implementation  strategics. 

In  this  paper  wc  give  a  unifying  presentation  and  systematic  comparison  of  type  systems 
(extended  to  reason  about  control-flow)  and  control-flow  systems  (extended  to  reason  about  type 
consistency).  The  type  systems  we  consider  arc  simple  types,  partial  types,  simple  recursive  types, 
and  recursive  subtypes.  Each  system  is  extended  in  a  generic  way  so  that  the  types  carry  control-flow 
information.  In  each  case,  the  extension  preserves  the  structure  of  the  underlying  lyp»;  system:  the 
same  set.s  of  terms  are  typable  under  the  extended  system,  and  in  fact  wc  can  fairly  ea.sily  translate 
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between  derivations  in  (he  extended  system  and  the  original  system.  The  control-flow  systems 
we  consider  are  “control -flow-0"  (n  standard  system  in  the  control-flow  literature),  a  system  based 
on  unification,  and  two  derived  systems  that  exclude  recursion.  In  each  case,  these  systems  are 
modified  to  reason  about  type  con.sistency  in  such  a  way  that  their  ability  to  reason  about  control-flow 

is  no(  changed.  Our  main  re.sult  is  that  the  families  of  types  systems  and  control-flow  systcm.s  arc 

equivalent  in  the  following  .sense:  for  each  type  system  there  is  a  control-flow  system  sucli  that  (i) 
both  systems  compute  the  same  control-flow  information,  and  (ii)  the  type  consistency  components 
of  both  systems  coincide. 

T\vo  main  technical  issues  arise  in  these  equivalence  proofs.  First,  type  systems  and  control- 
flow  systems  compute  over  dilTereni  representations.  For  the  type  systems  used  in  this  paper,  types 
can  be  viewed  as  (possibly  infinite)  trees  that  are  decorated  with  control-flow  information.  Each 
type  system  associates  one  of  these  trees  with  each  subexpression  of  the  program.  In  contrast,  the 
control-flow  systems  used  in  this  paper  compute  using  finite  sets  (which  essentially  contain  labels 
of  functions).  Each  control-flow  system  annotates  program  subexpressions  with  control-flow  sets. 
A  key  part  of  the  proof  involves  mapping  from  one  repre.sentation  to  the  other.  While  mapping  from 
a  type  to  a  control-flow  annotation  can  be  achieved  by  just  suppressing  type  structure,  the  mapping 
in  the  reverse  direction  is  more  complex:  it  involves  reconstructing  a  type  tree  using  the  annotations 
of  the  entire  program.  Thus,  type  information  is  not  explicit  in  the  control-flow  annotations,  but 
rather  it  i.s  di.stributed  over  the  entire  program.  In  c.sscncc,  the  control-flow  annotations  of  the 
program  collectively  represent  encodings  of  (potentially  infinite)  trees.  The  second  difficulty  is  that 
the  type  and  control-flow  systems  employ  different  notions  of  “consistency".  For  example  consider 
an  application  M  A'.  In  a  control-flow  system,  con.sistency  involve.s  considering  all  functions  that 
can  flow  to  M  and  reasoning  about  the  annotation.s  of  these  functions.  In  contrast,  a  type  .system 
would  reason  about  this  application  by  considering  just  the  types  associated  with  M  and  N.  Any 
information  about  the  functions  that  can  flow  to  M  is  already  represented  in  the  type  associated  with 
M.  In  .shon,  types  involve  only  local  reasoning;  control-flow  involves  highly  non-local  reasoning. 

The  equivalences  established  in  the  paper  reveal  much  about  the  underlying  stniclure  of  control- 
flow  and  type  systems.  For  example,  adding  recursive  types  to  a  type  system  corresponds  exactly 
to  allowing  cycles  in  the  control-flow  graph  computed  by  a  control-flow  analysis.  Similarly,  adding 
subtypes  to  a  type  system  corresponds  exactly  to  replacing  equalities  by  set  containment  in  the 
consistency  conditions  of  a  control-flow  system.  Our  results  also  provide  a  basis  for  exploiting 
the  advantages  of  both  the  type  and  control-flow  view.  From  the  point  of  view  of  implementing 
an  analysis,  it  is  usually  easier  to  start  from  a  control-flow  system.  Conversely,  for  the  purposes 
of  designing  a  modular  analysis  system,  type  systems  have  an  advantage  since  they  arc  usually 
presented  composifionally  (we  remark  that  one  of  the  original  motivations  for  this  paper  was  the 
development  of  modular  analysis).  In  addition,  certain  results  arc  sometimes  easier  to  prove  in  one 
system  that  the  other  (e.g.  correctness  becomes  a  subject  reduction  result  in  the  type  system,  and 
such  results  are  often  easy  to  establish). 
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Related  Work 


Previous  works  [1, 8]  have  established  that  the  typing  component  of  the  control-fiow-0  system  (when 
extended  to  reason  about  type  consistency)  is  more  accurate  than  simple  types  and  partial  types,  (VVe 
remark  that  the  equivalences  established  in  this  paper  can  be  viewed  as  an  alterative  explanation  of 
these  results.  Moreover,  on  combining  our  equivalence  results  with  obvious  relationships  between 
the  accuracy  of  type  systems,  we  obtain  a  number  of  additional  accuracy  relationships.)  Very 
recently,  Palsbei^  and  O’Keefe  [9]  have  independently  obtained  the  equivalence  of  the  typing 
component  of  control-flow-0  and  the  recursive  subtype  system  of  Amadio  and  Cardell  [  1].  We  also 
prove  this  result,  in  addition  to  analogous  results  for  three  other  control-flow  systems.  No  previous 
woiits  have  established  relationships  between  the  control-flow  component  of  (suitably  extended) 
types  systems  and  control-flow  systems. 


2  Preliminaries 


We  define  a  variant  of  the  A-calculus  with  labeled  abstractions.  The  reason  for  the  labels  is  that 
they  allow  us  to  talk  about  program  “control-flow”.  We  remark  that  the  language  is  suggestive  of 
an  intermediate  language  that  might  be  produced  by  a  compiler  front  end;  it  is  not  intended  as  a 
language  for  writing  programs.  Let  LABELS  be  a  countably  infinite  set  of  labels,  and  define  terms  c 
by: 


e  ;:=  x  |  X^x.c  \  e\e2  \  O  \  Sxicct. 

where  /  €  LABELS.  The  intention  is  that  labels  distinguish  different  occurrences  of  abstractions. 
Free  and  bound  occurrences  of  variables  in  a  term  are  defined  in  the  usual  way.  A  term  is  closed  if 
all  occurrences  of  variables  arc  bound.  A  program  is  a  closed  term  in  which  each  abstraction  has  a 
unique  label.  Evaluation  for  this  language  is  based  on  ,<?-reduction: 

(A^x.e)  e'  e[x/e'] 

where  denotes  the  result  replacing  of  t'  by  x  in  c,  after  appropriate  renaming  of  bound 

variables.  Note  that  this  process  preserv'es  labels  on  abstractions:  e.g.  (A'r.fr  j))  (A'’.t.(x  x)), 
— {X^'x.{x  x))  (A^'a:.(a:  t)). 

There  are  no  restrictions  on  the  reduction  order:  the  t?-reduction  can  be  applied  at  any  subterm 
at  any  time.  However,  wc  do  require  that  whenever  an  application  {e\  €2)  appears  in  a  term,  then  €| 
cannot  be  0  and  if  ej  is  Succ  then  e2  must  be  0  or  of  the  form  (5ucr  ■  •  •).  If  these  conditions  are 
not  met,  then  program  execution  terminates  with  an  error.  The  possibility  of  this  behaviour  leads 
to  a  very  natural  typing  problem  that  forms  a  key  part  of  this  paper.  Although  this  typing  problem 
arises  precisely  because  0  and  Succ  have  been  added  to  the  language,  wc  remark  that  our  results  are 
largely  independent  of  the  specific  choice  of  constants,  and  could  be  generalized  to  other  settings. 

The  language  also  gives  rise  to  a  natural  control-flow  problem:  given  a  program  eo.  construct  a 
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set  of  labels  L  such  that  if  to  evaluates  to  a  lambda  expression,  the  label  of  this  expression  will  be 
contained  in  L.  More  generally,  we  are  interested  in  the  sets  of  labels  for  subexpressions  as  well. 

lb  formalize  type  and  control-flow  systems,  we  shall  introduce  various  systems  for  “correctly” 
annotating  a  term  (and  all  of  its  subterms)  with  cither  type  or  control-flow  assertions.  In  general, 
these  annotated  terms  will  have  the  following  form:  if  >1  is  a  countable  set  of  annotations,  then  the 
A-annotated  terms  z  (or  just  annotated  terms)  are  defined  by: 

r  x:A  j  {A^a:.i):i4  |  (zi  !  0:A  1  (5!!CCt):.4 

where  .4  f  A.  Given  an  annotated  term  we  define  (mnot(z)  to  be  the  outermost  annotation  of  z. 
That  is.  annot{exp  :  >1)  is  A.  We  also  define  |r|  to  be  the  (standard)  term  resulting  from  stripping 
all  annotations  from  z.  Note  that  if  ^  is  a  collection  of  types,  then  an  annotated  term  is  essentially 
an  explicitly  typed  term;  such  a  term  carries  with  it  much  of  the  structure  of  a  typing  derivation  for 


3  Type  Systems  for  Control-Flow  AnnlysiS 


3.1  Simple  Types 

We  begin  by  describing  a  type  system  for  control- flow  analysis  b,ised  on  simple  types  (6).  Consider 
a  system  of  simple  types  where  lype.s  r  are  constructed  from  the  single  base  type  Jnt  and  — y  as 
follow's: 

r  ::=  Jut  \  ti  —) 

The  usual  formulation  of  simple  types  uses  a  deductive  .sy.vte.m  involving  Jitdgcmenf.s  of  the  form 
r  I"  f  :r.  Such  a  judgement  indicates  that,  in  the  context  P  (a  partial  mapping  from  variiables  to 
types),  t  ha.s  type  r.  However,  for  this  paper,  we  shall  need  to  simultaneously  associate  types  with 
all  of  the  subexpression  of  a  term.  Hence,  we  shall  formulate  our  type  sy.slem  using  type-annotated 
terms.  Using  such  terms,  the  standard  .simple  type  system  can  be  presented  as; 


r  r  r :  r  (if  j- :  t  appears  in  T) 
n.rrr,  !-  ^ 


r  h  ^‘x.z  :ri—*T2 

r  h  z  r  h  z' 
r  1  (c='):r2 


(if  rtnnof(r)  is  7:) 

is  ri-*T;  ar.tlannod:')  is  7i  ) 


r  h  0:/nf 

r  h  z 

r  (-  (5’urc  e) :  Jnt 


(if  nnno:'::)  is  /«;) 


(VAR) 

(AB.S) 

(.'\PP) 

(INT) 

(.sure) 
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(VAR) 


r  h  I :  r  (if  X  :  r  appears  in  F) 


r,  X :  rj  h  2 
r  1-  X^x.z\{L,T\-^ri) 

(if  /  6  i  and  annot(g)  is  tj) 

(ABS) 

r  z  r  H  a' 
r  F  {zz'):r2 

(if  annot(:)  is  {L.  Ti— ^rj)  and  annol(z')  is  rj  ) 

(APP) 

r  F  0;(L,/nt) 

(INT) 

r  F  a 

r  F  (Succ  a) :  (L,  Int) 

(ifcwno/(j)  is  (9,  Int)) 

(SUCC) 

Figure  1 :  Inference  rules  for  control-flow  type  system  based  on  simple  types. 


Vic  emphasize  that  this  is  just  a  reorganization  of  the  standard  formulation  of  simple  types.  We  now 
describe  a  uniform  method  for  enriching  a  type  system  to  perform  control-flow  analysis.  The  first 
step  is  to  enrich  types  so  that  they  carry  information  about  labels  of  abstractions.  Corresponding  to 
simple  types,  we  define  control-fiow  types  by; 

7  ;:=  (L.Int)  j 

where  L  ranges  over  finite  subsets  of  labels.  Note  that  the  set  of  labels  L  in  (I,  Int)  is  unnece.ssary 
because  no  functions  can  have  type  Inf,  we  retain  this  notation  for  uniformity  with  later  definitions. 
The  next  step  is  to  modify  the  typing  rules  of  the  system  to  accommodate  control-flow  types.  For 
simple  types,  we  modify  the  above  typing  rules  and  obtain  the  system  of  Figure  1 .  Note  the  side 
condition  on  the  ABS  rule  to  track  labels  of  abstractions.  We  write  K  z  and  say  that  z  is  correctly 
typed,  if  the  judgement  empty  K  ?  is  derivable  (empty  is  the  empty  context).  A  program  eo,  is 
said  to  be  K  -typable  if  there  cxi.sts  a  control-flow  annotated  term  z  such  that  (?(  =  co  and  s.  An 
important  property  of  the  control-flow  type  system  is  that  it  preserves  the  essentia!  character  of  the 
underlying  type  system.  In  particular,  the  set  of  typable  terms  remains  unchanged:  to  is  K  -typable 
iff  €o  is  typable  in  the  standard  simply  typed  system.  In  fact  there  is  a  very  close  correspondence 
between  the  two  systems.  If  K  t,  then  by  stripping  away  the  control-flow  information  in  the 
annotations  appearing  in  z,  we  can  construct  a  derivation  to  .show  that  |x|  has  simple  type  r  in  the 
simply  typed  system,  where  r  is  annot(z)  with  all  control-flow  information  removed.  Conversely, 
if  a  term  e  has  simple  type  r  in  the  .simply  typed  system,  then  we  can  look  at  the  derivation  of  ihi.s 
judgement,  and  by  systematically  inserting  trivial  control-flow  information^  obtain  an  annotated 
term  z  such  that  K  z  and  \z\  is  c.  The  control-flow  calculus  also  possesses  standard  properties 
such  a.s  subject  reduction: 

Proposition  1  (Subject  Reduction)  If  K  2  and  z  — z'  then  l->  z'.  [] 


This  property  establishes  not  only  the  correctncs.s  of  the  type  aspects  of  the  system,  but  also  its 
control-flow  aspects.  For  example,  if  K  e  :  t  and  c  reduces  to  A*x.e',  then  subject  reduction 
implies  that  -  must  have  the  form  (L.  such  that  /  €  L. 


'T7tjt  is.  each  type  t  is  sy.Uem.n(ic3!!y  rrp.'.wed  hy  rhe  s.\pR:.sw!.T  ,  r;.  tvhffC  I-,-  il  Stc  .'I!  Of  lab?!;  ' 
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We  now  address  the  controf-flow  component  of  the  system.  First  note  that  typing  i.s  not  unique: 
given  an  untyped  term  to.  there  may  be  many  correctly  typed  terms  c  such  that  |r|  =  For 
example,  corresponding  to  the  untyped  term  we  can  construct  a  family  of  correctly  typed 

terms: 


where  r  is  any  control-flow  type,  and  L  is  any  (finite)  set  of  labels  containing  /.  Part  of  this  choice 
lies  at  the  “type”  level;  there  is  also  choice  at  the  “control-flow"  level.  Recall  that  the  sets  of 
labels  that  are  associated  with  each  expression  in  a  correctly  typed  term  represent  an  upper  bound 
on  the  functions  that  can  flow  to  that  expression.  Smaller  sets  mean  more  accurate  control-flow 
information,  and  so  from  a  control-flow  perspective,  we  seek  annotated  terms  with  minimal  label 
sets. 

To  address  this  issue,  we  first  formalize  the  control-flow  content  of  an  annotated  term  c.  For 
any  control-flow  type  r,  define  that  cr(r)  (the  control-flow  component  of  r)  is  L  such  that  r  has  the 
form  {£,,  txp).  Lifting  this  to  annotated  terms  z,  define  that  CF(r)  denotes  the  result  of  replacing 
each  annotation  r  appearing  in  r  by  CFi'r).  That  is,  CF(^)  is  an  annotated  term  in  which  annotations 
arc  finite  subsets  of  LABELS;  this  term  idemifie.s  exactly  the  control-flow  content  of  c,  stripping 
away  the  extra  type  .structure.  Now,  there  is  a  natural  information  ordering  t>  between  control-flow 
annotated  terms  that  have  the  same  underlying  term  structure: 

•  t  :L  c>  ; IJ  if  A  D  and  e  is .r  or 0. 

•  (A'.r.a):L  t>  (V:r.e'):L'  if  L  D  h' md  z  t>  z'. 

•  (z]  Z2]:L  t>  {z\  z'2)'.L'  if  ADA'andci  C>  rj  and  rj  £> 

•  (.9»(r  z)  .L  C>  [Suf  c  z') :  //  if  1.  D  U  and  c  >  z' . 

We  remark  that  this  ordering  can  be  lifted  to  order  types  and  also  to  order  correctly  r-annotated 
terms.  The  resulting  orderings  would  give  a  covariant  treatment  of  functions.  Note  that  this 
ordering  cannot  be  u.sed  as  the  ba.sis  for  a  semantic  subiyping  relationship  -  even  ignoring  the 
“type”  component  of  control-flow  types,  it  is  not  the  case  that  "z\  i>  z^"  implies  that  a  subterm  ci 
of  r  can  be  replaced  by  si  to  obtain  another  correclly  typed  term.  Importantly.  >  gives  rise  to  a 
notion  of  minimality  with  respect  to  control  flow  information  (this  follows  directly  from  results  in 
Section  4): 

Proposition  2  (Minimality)  For  fwy  typabfe  program  Cq.  the  set  of  control-flow  annotatet!  terms 
{Cf-'{z)  :  \zl  =  f  niul  t;,  z]  has  a  mmiinal  element,  call  it  cr{t-^){co).  [] 

In  summary,  we  can  define  typing  and  controf-flow  aspects  of  f  j, 

•  Let  f;/pnhl(  (  \-^ )  denote  the  set  of  terms  typabie  under  r^ , 

•  Let  rnntrol-flow['ry )  dcnoie  the  partial  mapping  from  fo  intoCl'iK 


3^  Partial  Types 


The  second  control-flow  type  system  we  describe  is  based  on  partial  types  [13]  (with  constants 
0  ;  Int  and  Succ  :  Ini  Int).  Partial  types  extend  simple  types  with  a  new  type  Cl  that  is  a 
supertype  of  all  other  types.  To  illustrate  its  effect,  consider  the  term 

(A/....(/0)...(/Ay.O)...)(Ax.x) 

which  defines  the  identity  function,  binds  it  to  the  variable  /,  and  then  applies  it  to  an  integer  in  one 
place  and  an  integer  function  in  another.  It  is  not  possible  to  give  this  term  a  type  using  simple  types 
because  the  term  requires  that  /  simultaneou.sly  has  a  type  Int  t  and  a  type  (r'  — >  Int)  ->  r. 
However,  by  using  the  ft  type,  we  can  give  /  the  type  In  other  words,  Cl  can  be  used  to 

“unify”  different  types  (or  parts  of  types)  that  have  incompatible  stmclure,  but  little  can  be  done 
with  expressions  that  are  given  this  type  -  they  can  neither  be  applied  nor  used  as  an  argument  of 
Succ. 

We  extend  the  developments  of  the  previous  section  to  define  a  type  system  for  control-flow 
analy.sis  based  on  partial  types.  In  this  extended  system,  types  are  defined  by; 

r  {LJnt)  |  {L.Cl)  \ 

These  types  are  ordered  a.s  follows: 

•  (L,exp)  <  <L',a)  if  IC  // 

•  {L,  ti-*T2)  <  {Vy  if  £-  C  V,  rj  <  rj  and  ti  <  r^. 

Note  that  this  ordering  not  only  involves  the  “type”  structure,  but  it  also  involves  control-flow 
information.  For  example, 

— ¥lT\t)  <  (•{fi,  f2}i  +/nt) 

Typing  rules  for  these  types  can  be  obtained  by  modifying  the  rules  in  Figure  1  so  that  both  the 
as.sumptions  and  conclusions  of  the  rules  can  be  weakened  using  the  subtype  relationship.  The 
resulting  rules  arc  given  in  Figure  2,  and  we  write  z  if  empty  c  is  derivable  using 

these  rules.  Wc  remark  that  if  one  coasiders  only  typabzlity  questions,  then  we  could  ju.st  augment 
Figure  1  with  a  subsumption  rule.  However,  we  shall  con.sidcr  properties  of  type-annotated  terms, 
and  make  connections  with  these  annotations  and  annotations  obtained  using  control-flow  systems. 
For  these  purposes,  the  system  of  Figure  2  (for  which  there  is  a  simple  correspondence  between 
program  text  and  typing  rules)  is  advantageous. 

A  program  eo  is  said  to  be  'r  x^ajtypable  if  there  exists  a  control-flow  annotated  tema  z  such  that 
|c|  =  eoandF;^(n)  s.  As  in  the  previous  sub.section,  the  control-flow  type  system  and  the  underlying 
basic  type  system  (this  time  partial  types)  are  closely  related.  They  have  the  same  .set.'--  of  typablc 
terms,  and  derivations  in  one  system  can  be  replayed  (.after  appropriate  addition  or  suppression 
of  structure)  in  the  other  system.  The  1“a{r)  system  also  satisfies  the  subject  reduction  property 
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(VAR) 


r  h  x:r  (if  j- :  t' appears  in  Fanil  t' <  t) 
r,r:r'  h  r 


r  I-  :  {L,  r|— >“2) 

r  h  z  r  h  r' 


(if  Tj  <  Ti.annoiiz  )  <  r;  and  /  €  f.) 


(ABS) 


r  h  {zx'):7 
r  h  0:t  (if  (L, /nr)  <  r  ) 


(if  is  (£,.  T,— vtj).  ciniu)t[z''i  <  Ti  ai;<i  ft  <  r  )  (APP) 

(INT) 


r  h  5 


r  i-  {Slice  z):t 


(i{annot{z)  <  (0. /«.')  and  (G,/n!}  <  r) 


(SuCC) 


Figure  2;  Rules  of  inference  for  simple  subtype  system. 


(the  obvious  modification  of  Propo.sition  1).  Moreover,  the  t>  preference  ordering  can  be  used  to 
order  the  accuracy  of  control-flow  infonnation  in  annotated  terms.  An  appropriate  version  of  the 
minimality  proposition  (Proposition  2)  also  holds,  and  so.  given  a  V-^.o)  -typable  program  cq.  we 
can  define  a  “best”  control-flow  annotated  term  )(ro.)’  Hence,  typability  and  control-flow 

aspects  of  can  be  given: 

•  Let  )  denote  the  set  of  terms  typable  under  K;ni  • 

•  Let  contrfll-J]o\v{-xia) )  denote  the  partial  mapping  from  ro  ifito  CF(K,ni  ){fo)- 


Recursive  Types 

The  third  .system  is  based  on  recursive  types,  another  extension  of  simple  types.  This  time  types  are 
extended  by  adding  a  fir  point  construction  /lo.r.  The  effect  of  this  addition  is  that  terms  involving 
recursion  such  as  (A'.r.(j:  j-))  (A*'i.(r  t))  can  be  typed.  To  define  a  control-flow  type  sy.stcm  based 
on  recursive  types,  we  first  define  open  types  to  be  expressions  of  the  following  form: 

CT  ::=  a  I  {L.Int)  \  I  /ro.rr 

where  o  range.s  over  a  countably  infinite  collection  of  type  variables,  and  ;to .  is  treated  as  a  binding 
construct.  Free  and  //-bound  occurrences  of  type  variables  in  open  types  are  defined  in  the  u.sual  way. 
VVe  define  an  equality  on  open  types  by  po.a  =  (t[p<\ .a / <\],  where  <T[//o.a/o]  denotes  the  rc.suli 
of  replacing  free  occurrences  of  o  by  //a.t  in  r  (after  renaming  of  bound  variables,  if  necessary). 
This  i.s  extended  in  the  obvious  way  to  become  a  congruence  on  open  types:  if  <T|  -  rri  and  o'  is  the 
rc.sult  of  replacing  <T|  by  cr?  in  a  then  o'  =  o.  Finally,  types  r  are  defined  to  be  (hose  expre.ssions  o 
that  do  not  contain  free  type  variables. 

The  typing  nilc.s  for  this  new  sy.stcm  consist  of  exactly  the  rules  previously  given  itt  Figure  3. 1 . 
Wc  write  t- ,  e  if  erupt i>  I-  s  is  derivable.  A  program  fp  is  .said  to  he  iw^.  ytypohle  if  them  exi.sts 
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a  conirol-flow  annotated  term  z  such  that  |s|  =:  cq  and  z.  This  control-flow  type  system 
preserves  many  of  the  basic  properties  of  the  underlying  recursive  type  system.  Tlie  set  of  typable 
terms  is  the  same,  and  subject  reduction  is  preserved.  An  appropriate  version  of  the  minimality 
proposition  (Proposition  2)  also  holds;  for  a  -typable  program  co.  let  CF(K(p)  )(eo)  denote  the 
minimal  control-flow  annotated  term  thus  obtained.  Typability  and  control-flow  aspects  of  can 
now  be  defined: 

•  Let  )  denote  the  set  of  terms  typable  under  K(^)  ■ 

•  Let  contml-flow{\-xi^) )  denote  the  partial  mapping  from  into  cf(K;^.,  ) (trj). 


3.4  Amadio/Cardelli’s  System 

f 

Finally,  we  define  a  control-flow  type  system  that  combines  partial  types  and  recursive  types.  The 
starting  point  of  this  development  is  essentially  Amadio  and  Cardelli’s  recursive  subtype  system 
[IJ  (with  extensions  for  0  and  Succ).  For  definitional  convenience,  we  shall  use  a  formulation  of 
recursive  subtypes  that  differs  slightly  from  those  used  previously  in  the  literature  [1,  5,  9].  We 
therefore  begin  by  pre.senting  this  system  without  the  control-flow  information  component.  Define 
e.xpressions  c  by 

<r  a  |  Int  fl  |  <Ti-><T2  |  fia.CT 

where  a  range.s  over  type  variables.  Occurrences  of  types  variables  arc  defined  to  be  free  and 
p-bound  in  an  expression  a  in  the  usual  way.  Again  we  define  a  congruence  on  open  types:  pa.cr 
=  a]j.to,.alck].  Types  r  are  defined  to  be  those  expressions  a  that  do  not  contain  free  type  variables. 

Next,  we  define  an  ordering  between  types  (strictly  speaking,  this  ordering  is  between  equiva¬ 
lence  classes  of  types).  This  ordering  is  defined  by  successive  approximation  (see  [1,5]  for  related 
constructions).  Specifically,  define  an  ordering  <i:,  k  >0,as  follows: 

•  '  <0 

•  r  <k  Cl 

•  pO.O  <k  T 

•  <k  Int 

•  ~i— >”2  <ji.  if  r|  tj  and  T2  <2 

where  t  and  t'  are  arbitrary  types.  We  now  define  that  t  <  r’  \(  r  <k  t'  for  all  k  >  0.  If  we  ignore 
Int,  identify  T  with  Q  Snd  treat  J.  as  shorthand  for  fiQ.o,  then  this  ordering  is  equivalent  to  the  one 
given  by  Amadio  and  Cardelli  (call  it  <c:)  in  the  following  sense: 

Propositions  For  oil  and  T2  not  containing  Int,  T]  <  T2  iff  '1  <ac  "i-  Q 
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To  exlend  this  system  to  control-flow,  we  first  define  open  types  a  by: 

a  ::=  o  [  {L,Int)  |  (L.Q)  |  (  //o.cr 

where  o  ranges  over  type  variables.  Tlien,  types  t  are  those  expressions  a  that  do  not  contain  free 
type  variables.  A  congruence  on  types  is  defined  by  fin.P  =  a[fia.a/a],  and  an  ordering  <1,.  k  >  0, 
is  defined  by: 

•  7-  <0  r' 

•  {L,txp)  <1:  \V,Q)  if  L  C  L' 

•  {L.po.a)  <;■  {L\f.ip)  if  L  C  L" 

•  {L,Irit)<k  (L'Jni)  if  L  C  L' 

•  <t  (L' ,  if  <t_i  T\.  72  ^t--)  7j  and  I,  C  I/. 

We  define  that  r  <  r'  if  t  <i.  r'  for  all  A-  >  0.  The  inference  rules  for  these  types  are  the  exactly 
those  from  Figure  2.  We  write  to  denote  the  type-correctness  judgement  thus  defined.  Again 

subject  reduction  carries  over  to  the  control-flow  types  system,  and  typability  for  the  control-flow 
system  coincides  with  that  for  the  underlying  Amadio/Cardelli  system.  An  appropriate  version  of 
the  minimality  proposition  (Proposition  2)  also  hold.s,  and  so  we  can  define,  given  a  -typable 
program  ea,  the  minimal  control-flow  annotated  version  of  co.  call  it  CF(  (-*(0  )(«())•  Typability 

and  control-flow  aspects  of  h  can  now  be  given: 

•  Let  ty/Mibk  ( )  denote  the  set  of  terms  typnble  under  K.ii  . 

•  Let  control-J\ow{  Kiti,  „) )  denote  the  partial  mapping  from  cq  into  Cr(  )  (co) . 


4  Control-Flow  Analysis 


The  purpose  of  control-flow  is  to  dctcmiinc  information  about  the  functions  that  can  be  called  from 
various  program  points  during  execution  of  a  program.  In  the  following  development,  a  function 
shall  be  identified  its  label.  We  define  control-flow  systems  using  annotated  terms  and  consistency 
conditions  bctw'cen  “neighbouring”  annotations.  By  vary  ing  these  consistency  conditions  and  .some 
additional  properties,  we  shall  define  a  family  of  four  control-flow  systems. 

If  we  were  concerned  only  with  control-flow  information,  it  would  be  sufficient  to  annotate 
terms  using  control-flow  flow  information  (finite  subsets  of  LABELS).  However,  we  wish  to  construct 
control-flow  sy.stems  that  capture  typing  properties  (in  addition  to  control-flow  properties),  for  the 
purpose  of  establishing  closer  links  with  the  type  systems  presented  in  Section  3.  Hence,  we  shall 
use  annotations  7  that  arc  finite  subsets  of  LABELS  u{/nt}.  Our  presentations  of  control-flow 
sy.stems  is  closely  related  to  those  by  Palsberg  and  Schwartzbach  (7,  8J. 
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4.1  Standard  CFA 


We  begin  a  sysiein  that  corresponds  to  a  widely  studied  notion  of  control-flow  analysis  [3, 4, 10, 7, 8], 
often  called  control-flow-0.  The  system  we  give  is  equivalent  to  the  sy.stem  de.scribcd  by  Palsberg 
and  Schwartzbach  in  f7,  8].  The  only  difference  is  in  presentation;  we  directly  use  annotated  terms 
instead  of  set  variables  and  constraints.  We  present  the  sy.stem  by  defining  that  an  annotated  term  z 
is  well-annotated  if  it  satisfies  the  following  conditions: 

1 .  if  appears  in  z  then  /  6  7. 

2.  if  (zi  S2) appears  in  c  then  Int  ^  arinot(si)  and  for  a!! !  nnnot{z.\)^  if  annears 
in  z  then: 

(a)  annol[z*)  C  7, and 

(b)  if  X  occurs  free  in  c'  with  annotation  7x  then  annot{z2)  C  7^.. 

3.  if  0 : 7  appears  in  2  then  72  { /n/} 

4.  if  (Sure  z'):'i  appears  in  2  then  7  3  {fnt}  and  a.nnoi{z')  C  {Int}. 


Wc  shall  refer  to  this  system  as  CFAc .  As  in  the  previous  section,  we  shall  define  typing  and  control- 
flow  properties  of  this  system  by  relating  untyped  programs  and  annotated  terms.  First,  consider 
typing.  Define  that  a  program  co  is  CFA c -type-consistent  if  there  exists  an  annotated  term  2  such 
that  Co  =  [rl  and  2  is  well-annotated  according  to  the  above  definition.  Next  consider  control-flow. 
Clearly  there  will  in  general  be  many  well-annotated  versions  of  cq.  each  identifying  potentially 
ditTereni  control-flow  information.  These  terms  can  be  related  using  the  ordering  t>  defined  in 
Section  3.  Strictly  speaking,  >  orders  terms  that  are  annotated  with  finite  subsets  of  LABELS,  but  it 
can  clearly  be  generalized  to  order  any  annotated  terms  where  the  annotations  are  sets. 


Proposition  4  (Minimality)  For  any  CFAc-type-consistent  term  €0,  there  is 
annotated  term  z  such  that  jc!  =  to-  {] 


tvcii- 


This  proposition  follows  from  the  fact  that  well-annotated  terms  arc  closed  under  intersection. 
Specifically,  if  cj  and  zz  are  wcll-annotnted  terms  such  that  {21  ]  =  1221  then  wc  can  define  an 
annotated  term  2j  n  22  by  intersecting  the  corresponding  annotations  of  21  and  22.  and  this  new 
term  will  be  well-annotated  and  such  that  I21I  =  jril  =  jsi  D  This  follows  immediately  from 
inspection  of  the  well-annotated  conditions. 


Using  Proposition  4,  wc  can  define  the  control-flow  component  of  CTAc  ■  First,  recall  that 
annotated  terms  u.sed  in  the  system  may  include  Int.  To  give  just  the  control-flow  information  of 
an  annotated  term,  let  CFfr)  denote  the  result  of  replacing  each  annotation  in  .4  appearing  in  2  by 
A  -  {/nt}.  Finally,  given  a  program  co  that  is  CRAg-iype-consistcnt,  define  that  CF(CFAc)(eo) 
CF(2)  where  2  is  the  t>-minimal  well-annotated  term  such  that  |2|  =  to.  Wc  can  now  define  typing 
and  control-flow  aspects  of  CFAc  as  follows: 

•  Let  typablt  (CRAc )  denote  the  set  of  type-consistent  terms  under  CFAc . 

•  Let  control-flow{cF.\c )  denote  the  partial  mapping  from  »  o  into  CF{CrAc ) 


n 


4.2  Standard  CFA  without  Recursion 


The  CFAc  system  defined  in  the  previous  subsection  can  reason  about  recursion.  For  example,  one 
well-annotated  version  of  {A';r.(j  x))  (A''j-.(3*  j))  is 


((.\'r.(i:(n  *:{/')) :  {))  :  {/)  :  (1) :  {''))  :  {} 


We  now  define  a  control-flow  system  that  is  based  on  equality  but  specifically  excludes  programs 
involving  recursion.  In  this  modified  system,  an  annotated  term  c  is  well-annotated  if  it  satisfies  the 
conditions  given  in  Sub.section  4.1  and  in  addition  there  is  a  non-reflexive  ordering  >-  on  LABELS 
such  that 


•  if  X‘x.z':~i  appears  in  :  and  .r  occurs  free  in  c'  with  annotation  7j.,  then  (V7'  £  ';v)(/  >-  lO- 

Call  this  system  CFAr.-.v.  A  program  eo  is  if  ihi^re  exi.sts  an  annotated 

term  c  such  that  eQ  =  |rj  and  z  is  well-annotated  according  to  the  above  definition.  Given, 
a  type-consistent  program  cq,  we  can  again  use  t>  to  define  a  unique  minimal  well-annotated 
term  corresponding  to  cq,  and  so  using  CF  we  can  CF(CFAc;.-,v  )(<'o)  >n  analogy  with  the  previous 
subsection.  Hence,  typing  and  control-flow  aspects  of  CFAc.-.v  can  be  defined; 

•  Let  r(//wWr(CFAc,->r)  denote  the  set  of  type-consistent  terms  under  CFAc.-,r- 

•  Let  coiitrol’flon  {CFAc .-y)  denote  the  partial  mapping  from  fo  into  CF(chAc.-v) 


4,3  CFA  via  Equatity 

The  next  system  we  consider  essentially  corresponds  to  the  analysis  con.sidcred  by  Bondorf  and 
Jorgensen  [2].  The  only  difTcrences  are  that  we  do  not  consider  arbitrary  daia-constnictors,  and  \vc 
include  Int  to  reason  about  type  consistency.  The  definition  of  well-annotated  programs  for  this 
system  is  a  modification  of  the  definition  in  Subsection  4.1  in  which  subset  is  replaced  by  equ.ality. 
Specifically,  an  annotated  term  c  is  w  ell-atmntaied  if: 

1.  if  (A'x.c')  :7  appears  in  z  then  I  €  7. 

2.  if  (ci  C3} appears  in  r,  /  C  annnlizi)  and  A*j-.r'  appe.ars  in  *  then: 

(a)  ati7iot{z')  =  7,  and 

(b)  if  .r  occurs  free  in  z'  with  annotation  *,j.  then  ui)u(A\zi)  =  7^  . 

3.  if  0:7  appears  in  c  then  7  =  {Id!) 

4.  if  (Slice  z'):'i  appears  in  c  then  7  =  annot(z')  s=  {Int}. 

Call  thi.s  system  CFa^.  Definitions  of  lypc-consistcncy.  minimalit)  and  ('F(CFAa)(ro)  can  be 
given  analogously  to  those  in  the  previous  sub.scclions.  Typing  and  control-flow  aspects  of  CFA- 
arc  defined  by: 
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•  Let  iy)wble{CFAi-)  denote  the  set  of  type-consistent  terms  under  CFA=. 

•  Let  conirol-flow{c\-'i\-)  denote  the  partial  mapping  from  ey  into  CF(ChA  ) 


4.4  Standard  CFA  without  Recursion 

As  with  CFAc,  the  CFA=  system  can  reason  about  recursion.  We  now  define  a  fourth  control-flow 
analysis  system  that  combines  CFA=  with  the  recursion  restriction.  In  this  new  system,  an  annotated 
term  e  is  well-annotated  if  it  satisfies  the  conditions  given  in  Subsection  4.1  and  in  addition  satisfies 
the  recursion  restriction  given  in  Subsection  4.2.  Call  this  system  CFA=.-,y.  Definitions  of  type- 
consistency,  minimality  and  CF(CFA=,-,v  )(eo)  can  be  given  analogously  to  those  in  the  previous 
subsections.  T^'ping  and  control-flow  aspects  of  CFA=  arc  defined  by: 

•  Let  typnhle{c¥\-^^y)  denote thc  Set  of  typc-conssstcnt  terms  under 

•  Let  control-flow{CF\-  .,y)  denote  the  partial  mapping  from  fo  into  CF(CFA-..,v) 


5  1^7)68  =  Control-Flow 


We  now  establish  a  series  of  corre.spondences  between  the  four  type  systems  and  thc  form  control 
flow  systems  that  have  been  presented.  In  short,  we  prove  the  following  equivalences: 


K  =  CFA=.-,y 

=  CFA= 

K(Q)  =  CFAj,-,^ 

K(q,,,)  =  CFA  2 

That  is,  thc  two  subtype  systems  correspond  to  the  control-flow  systems  based  on  C;  the  two  other 
type  systems  correspond  to  the  control-flow  systems  based  on  =.  Non-recursive  type  systems 
correspond  to  control-flow  systems  that  exclude  control-flow  cycles,  and  recursive  type  systems 
correspond  to  control-flow  systems  that  do  not  restrict  control-flow  cycles. 

For  each  pair  of  type  and  control-flow  system,  wc  establish  that  thc  type  and  control-flow 
components  of  thc  systems  correspond.  For  example,  for  K  and  CFa=,-,v  we  prove  that  (a) 
typable(  K  )  ==  ly}Mihle(CFA=,^Y),  and  (b)  coniroUflow(  K  )  =  control-flow(C¥\s-Y).  These 
connections  are  proved  by  showing  that  a  “correctly  annotated”  term  in  one  system  can  be  used  to 
reconstruct  a  closely  related  “conectly  annotated”  term  in  the  other  system.  Specifically,  for  each 
pair  of  systems,  wc  prove  thc  following  two  theorems: 

Theorem  1  Ifztypc  is  correctly  typed  then  there  exists  a  well-annotated  term  such  that  \  r.yj,,.]  = 

,  -cj'a|  and CFiziypf.) 

Proof  Sketch(for  Km.^)  and  cfa^)  Suppose  that  K(tj ,.)  Unfortunately,  we  cannot  proceed 
to  define  a  well-annotated  term  directly  using  the  control-flow  information  in  2,^^.  because 
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there  is  some  slack  in  the  definition  of  correctly  typed  terms  with  respect  to  the  specification  of 
control-flow  information.  In  essence,  the  set  of  control-flow  information  associated  with  a  term 
can  often  be  enlarged  using  subtyping,  without  affecting  correctness  of  the  type  annotations.  Due 
to  minor  structural  differences  between  type  systems  and  control-flow  analysis,  such  enlargements 
cannot  nece.ssarily  be  replayed  in  a  control-flow  analysis.  Hence,  we  must  first  trim  this  slack.  In 
the  conte.xt  of  define  a  function  trim  on  types  as  follows:  irim{r)  is  the  result  of  replacing 
the  control-flow  component  of  r  with  the  set  of  all  labels  /  e  CF(r)  .such  that  if  :  t/  appears  in 
Cfy;,f,then7-/  <  r.  Then,  define  that is  the  annotated  term  such  that  all  types  r  appearing 
in  Zf-ipt  (and  subexpre.ssions  thereof  that  are  types)  are  systematically  replaced  by  fnm(r).  It  is 
easy  to  verify  that  K.-n  ,.i  fMin(r,yp.)  and  that  t> 

Now,  consider  systematically  replacing  the  annotations  in  trim  )  as  follows:  an  annotation 
r  is  replaced  by  CF(r)  U  {/id)  if  ({},  Int)  <  r  and  CF(7)  otherwise.  Cali  the  resulting  term  z.j,.. 
Clearly  and  CF(c,,,p,)  C>  CF(r,-/a)-  remains  lo  show  that  is  well-annotated 

according  to  the  control-flow  definitions.  This  i.s  mostly  straightforward;  the  mo.st  interesting  case 
is  application,  and  here  the  proof  follows  the  following  property  of  any  annotation  appearing  in 

fnm(z,yp,) 

if  I  £  CF(r)  and  A^r.r  ;  r;  appears  in  tnm(zf^pf).  then  7/  <  t. 

This  is  an  immediate  consequence  of  the  trim  construction.  Q 

The  proof  for  the  other  three  cases  of  this  theorem  are  modifications  of  this  basic  result.  For 
type  .sy.stems  that  do  not  include  recursion,  the  above  construction  can  be  modified  to  yield  a  well- 
annotated  terms  that  does  not  involve  control-flow  cycic.s.  For  type  systems  that  do  not  involve 
subtyping,  the  type  sy.stems  do  not  include  the  subtyping  rule,  and  when  translated  to  well-annotated 
tenm  (via  the  above  construction),  ihi.s  means  that  the  control-flow  consistency  conditions  become 
equalities  rather  than  inclusions, 

Theorem  2  l/zc/^  is  well-annotated  then  there  exists  a  correctly  typed  term  such  that  |-c/u!  = 

I I  CF^C-y,,)  —  CF(Cfj|n«). 

Proof  Skctchffor  and  CFA^)  Suppose  that  r-/-  is  well-annotated  according  to  CFAc.  and 

consider  the  following  translation  7  (7)  from  the  annotations  7  appearing  in  Zeja  into  types: 

ri  if7  =  {} 

.1  Int  ir7  =  {/«0 

-  {-,:T(duw{y))-*T{ran{y)))  if  7  ^  {}  and  7  C  LABELS 

T  otherwise 

\ 

where  dom  and  ran  arc  defined  by: 

(iotn  (7 )  =  n{7  :  X‘:r.z  appears  in  and  some  free  occurrence  of  .r  in  ;  has  annotation  7} 
/Y/;j(7)  =  :  A'.r.r  appears  in 
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To  explain  these,  consider  an  abstraction  X‘t.z  appearing  in  Annotations  on  the  free  occur¬ 
rences  of  I  in  s  represent  upper  bounds  on  the  arguments  to  which  this  abstraction  can  be  “safely” 
applied.  Hence.  dom(y),  the  intersection  of  these  annotations  over  all  /  €  7,  is  the  largest  set  that 
satisfies  all  of  these  bounds,  and  this  represents  an  upper  bound  on  possible  applications  of  a  term 
with  label  7.  Similarly,  r(in(7)  represents  a  lower  bound  on  the  possible  results  of  an  application 
of  a  term  with  annotation  7.  Observe  that  the  above  translation  defines  an  infinite  object  if  Zf/a 
involves  control-flow  cycles.  To  deal  with  this  situation,  we  modifj’  the  mapping  T  as  follows. 
First,  we  set  aside  a  collection  of  distinct  type  variable  cu,  for  each  annotation  7.  We  then  modify 
the  above  definition  to  give  a  translation  1'^  which  carries  the  sequence  of  annotations  7  that  have 
already  been  considered.  The  key  modification  is  the  part  for  arrow  types:  if  7  C  LABELS  then 
7^(7)  is 

0-,  if  7  e  7 

(7,2^’'^{dom(7)) -»  T'^-'^{ran{';)))  otherwise 

In  other  words,  the  recursion  operator  fi  is  used  to  fold  infinite  types  into  finite  ones.  Now  define 
that  T(t)  is  r*(r)  where  0  denotes  the  empty  sequence.  A  key  property  of  T  is  that  if  7j  C  72  then 
Q  ^■(72).  Finally,  define  that  Ztypes  is  the  term  that  results  from  systematically  replacing 
each  annotation  7  in  Zeja  by  r(7).  Clearly  \zc}a\  =  l-^typel  and  CF(Zf /a)  =  CF(rtype),  and  it  only 
remains  to  show  that  is  correctly  typed.  This  is  essentially  a  structural  induction  on  ztypes 
(although  note  that  contexts  have  the  be  constructed),  and  is  fairly  straightforward.  [] 

Again  the  proof  for  the  other  three  cases  of  this  theorem  are  modifications  of  this  basic  result. 
For  control-flow  systems  that  exclude  recursion,  note  that  the  original  definition  of  T  is  sufficient 
since  the  ordering  >-  on  LABELS  means  that  cyxles  cannot  appear  in  this  definition.  Hence,  it  is  clear 
that  the  image  of  T  con.sists  of  non-recursive  types.  For  control-flow’  systems  that  do  not  involve 
subtyping,  the  control-flow  consistency  conditions  become  equalities  rather  than  inclusions.  When 
translated  to  types,  such  annotations  correspond  to  type  derivations  that  do  not  require  subtyping 
(we  remark  that  when  the  above  construction  is  applied  to  a  CFA:=_-,j/-well-annolated  tenn,  the 
resulting  term  can  contain  J.;  by  replacing  such  occurrences  by  IpA,  we  obtain  the  desired  result). 
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